The cost of computing and networking technologies have fallen to the point where computing and networking capabilities are now being built into the design of many electronic devices in the home, the office and public places. The combination of inexpensive and reliable shared networking media with a new class of small computing devices has created an opportunity for new functionality based mainly on the connectivity among these devices. This connectivity can be used to remotely control devices, to move audio, video and still images in the form of digital data between devices, to share information among devices and with the Internet and to exchange structured and secure digital data to support things like electronic commerce. A prevalent feature of these connectivity scenarios is to provide remote access and control of connected devices and services from another device with user interface capabilities (e.g., a universal remote controller, handheld computer or digital assistant, cell phones, and the like). This trend of ubiquitous and pervasive networked computing leads toward a world in which all types of devices are able to effortlessly and seamlessly interconnect and interact.
Peer networking connectivity protocols are now being introduced to facilitate connectivity among these pervasive networked computing devices, such as by enabling a device to dynamically join a network, obtain an address on the network, convey its capabilities, and discover the presence and capabilities of other devices while avoiding burdensome set-up, configuration and software driver installation by the user. Examples of current such peer networking connectivity protocols include Universal Plug and Play (UPnP), JINI, HAVI, Salutation, and others.
The capability provided in these peer networking connectivity protocols of enabling discovery of the presence and capabilities of devices present on the network can pose a security problem in many use scenarios. For example, with the UPnP protocol as presently defined, devices periodically transmit a multi-cast HTTP announcement to the network. Further, devices respond to multi-cast HTTP discovery requests received from the network. The announcements and discovery responses identify the type of device and its capabilities, as well as its presence on the network.
The problem arises in that common networking media are open and accessible to any device with physical access to the networking media, such that this discovery capability may be accessible to use in eavesdropping or surveillance by unknown outsiders. For example, many home networks where UPnP is intended to be deployed may be built using wireless and power-line networking media (e.g., IEEE 802.11(b) wireless networking standard). Computing devices equipped with appropriate network adapters that are operated within range of the wireless network (e.g., in a van parked along the nearby street) or plugged into a home's exterior power outlets for a power-line network potentially could conduct discovery of the home's electronic appliances via the discovery capabilities of peer networking connectivity protocols. This capability might then be put to illicit use in criminal activity to “case” the house for valuable appliances (e.g., high-end audio/video media equipment) before attempting break-in and theft. This vulnerability of peer networking connectivity protocols is of particular concern because the discovery capability reveals not only the presence of devices on the home network, but also their nature.
Cryptographic techniques can be used to protect confidentiality of communications between devices (e.g., via cryptographic encryption of data), protect message integrity (e.g., via a cryptographic checksum), authenticate sender identity (e.g., via a digital signature or message integrity check), and verify information presented by the sender is certified by a trusted authority (e.g., via digital certificates). Cryptographic encryption techniques can be based on well known symmetric key and public key encryption algorithms, such as the National Bureau of Standards' Data Encryption Standard (DES), Triple DES, the National Institute of Standards and Technology's (NIST) Advanced Encryption Algorithm (AES), the Diffie-Hellman-Merkle Algorithm, the RSA Algorithm, and the ElGamal Algorithm. Cryptographic checksum techniques can use well known message-digest algorithms, such as MD2, MD4, MD5, SHA and SHA-5. Digital signatures can use the well known NIST Digital Signature Standard (DSS), and the Digital Signature Algorithm (DSA). A well known digital certificate technique includes the X.509 digital certificate standard of the International Telecommunication Union-Telecommunication Standardization Sector (ITU-T) and ISO/International Electrotechnical Commission (IEC).
One obstacle to use of cryptographic techniques to secure peer networking connectivity protocols is that encrypting such communications generally contradicts the objective of such protocols of enabling dynamic, immediate interaction among devices without burdensome user configuration requirements. More specifically, a general objective of peer networking connectivity is that a network-ready device can immediately inter-operate with other devices on a network upon joining the network. For example, a handheld computer, video camera or any other variety of device equipped with a wireless network adapter can begin inter-acting with other devices on a wireless Ethernet (802.11b standard) network upon coming within the reception range of the network and without requiring extensive user configuration or driver installations.
A more particular obstacle to use of these cryptographic techniques for securing discovery and other device interactions via peer networking protocols is the well-known key management problem. In the currently available IPSec Internet Security Protocol, for example, each pair of devices (e.g., devices A and B) generates a pair of cryptographic keys (e.g., keys KAout,Bin and KBout,Ain) referred to as a “Security Association (SA)” to encrypt communications exchanged between the devices. (See, S. Kent, R. Atkinson, “Security Architecture for the Internet Protocol,” IETF RFC 2401, November 1998.) The number of cryptographic keys required by the system therefore would generally increase exponentially with the number of devices that are to interact with all other devices in the system (e.g., (n2−n) cryptographic keys for 2 cryptographic keys per communicating pair of devices).
Establishing and managing this large number of keys can be a particularly significant impediment in common peer networking connectivity protocol contexts, such as in the home or small business environments, where professional network administration is not available. With a trend towards pervasive networked computing, such unmanaged networks may predominate. For example, device manufacturers cannot expect the average non-technically savvy consumers to be willing or capable of setting up complex cryptographic key configurations for their now-pervasively-networked home appliances. Again, the peer networking connectivity-enabled device should just inter-operate with other peer devices without extensive user configuration requirements.
Existing solutions to the key management problem, however, are inappropriate to secure communications in many applications of a peer networking connectivity protocol, due to their complexity, code size, requirement for a server intermediary, and/or requirement for end user configuration. The Kerberos protocol, for example, requires a Key Distribution Center (KDC) or trusted Kerberos server to manage an exchange between two devices to establish a “session key,” for encryption of the devices' intercommunications during a session. (See, e.g., J. G. Steiner, B. Clifford Neuman, and J. I. Schiller, “Kerberos: An Authentication Service for Open Network Systems,” Usenix Conference Proceedings, March 1988; and J. Kohl and C. Neuman, “The Kerberos Network Authentication Service (V5),” IETF RFC 1510, September 1993.) Peer networking connectivity protocols desirably facilitate peer-to-peer interaction of devices without requiring the presence of a central server on the network.
As further examples, the Internet Key Exchange (IKE) protocol (used for dynamically creating security associations in the IPSec protocol) is a hybrid protocol to negotiate, and provide authenticated keying material for, security associations between pairs of devices in a protected manner. (See, D. Harkins, D. Carrel, “The Internet Key Exchange,” IETF RFC 2049, November 1998.) The Group Key Management Protocol (GKMP) creates key for cryptographic groups, distributes key to the group members, ensures (via peer to peer reviews) rule based access control of keys, denies access to known compromised hosts, and allow hierarchical control of group actions. (See, H. Harney, C. Muckenhirn, “Group Key Management Protocol (GKMP) Specification,” IETF RFC 2093, July 1997.) Although IKE and GKMP are capable of producing cryptographic keys in a direct exchange between peer devices, the IKE and GKMP protocols are complex and have a code size that is too large for many small and inexpensive embedded computing device applications.
The present invention provides ways to secure communications in a peer networking connectivity protocol, such as to prevent discovery and other interactions with untrusted devices, while minimizing user configuration requirements. In one embodiment described herein, communications in a peer networking connectivity protocol among at least one class of trusted devices on a network are encrypted with a group cryptographic key. These devices respond only to discovery requests that are encrypted using the group cryptographic key, and send announcements that also are encrypted using the group cryptographic key. This encryption of the devices' peer networking connectivity communications using a group key effectively forms a trust web that permits peer networking connectivity among the trusted devices, while preventing untrusted devices that have not been keyed with the group cryptographic key from conducting discovery or accessing services of the trusted devices.
In this embodiment, devices initially have a device-specific cryptographic key when purchased by an end user. For example, the devices are keyed with individual device-specific cryptographic keys by their manufacturer. The device-specific cryptographic key preferably is unique to the individual device, but the same cryptographic key can be assigned to multiple commercially distributed devices (e.g., randomly, particular model of device, etc.). The device will then use the device-specific cryptographic key to encrypt and decrypt communications via the peer networking connectivity protocol. This means that the device will only accept communications (including discovery, re-keying commands, etc.) from a “trusted” device that possesses the same device-specific cryptographic key.
Upon installation or deployment of a new device in the user's network, the new device is re-keyed with the group cryptographic key, so that the new device can then inter-operate within a trust web of other devices that also are keyed with the group cryptographic key. In this embodiment, re-keying is accomplished by sending a re-keying command to the new device over a secure communications channel created by symmetric key encryption using the device-specific cryptographic key. For example, the re-keying command can be sent from a group keying device, which may be a group keying utility program run on a personal computer or other computing device on the network. The device-specific cryptographic key of the new device can be provided to the user on a label or other tag that comes attached to the new device. The user enters the device-specific cryptographic key into the group keying device and activates its re-keying process. In the re-keying process, the group keying device uses the device-specific cryptographic key to encrypt its communications with the new device, which may include discovery requests in the peer networking connectivity protocol as well as the re-keying command. In its re-keying command, the group keying device specifies the group cryptographic key for keying the new device (i.e., substituting for the prior device-specific cryptographic key). The new device is then keyed to use the group cryptographic key to inter-operate in the trust web of devices also keyed with the group cryptographic key.
This re-keying process has the advantage that only the user who has possession of the new device and its device-specific cryptographic key label is able to key the new device. Further, since the device is initially keyed to accept only peer networking connectivity protocol communications that are encrypted with the device-specific cryptographic key, the device is first re-keyed with the user's group cryptographic key before it is able to inter-operate with the user's other devices. This helps to prevent outside others who may gain access to the user's network from keying the user's devices, and helps prevent any tendency of consumers to leave initially un-keyed devices un-keyed (and hence open to possible discovery and control by outsiders as discussed above).
A further advantage of the re-keying process over manually keying each device in a trust web is that not all devices need be equipped with a key pad for manual entry of the group cryptographic key. Instead, the device-specific cryptographic key of the new device is entered into the keying device, which then securely transmits the group cryptographic key to the new device in the re-keying command. This permits devices that don't normally have numeric key pads (e.g., alarm clocks, furnaces, etc.) to be keyed with the group cryptographic key without being equipped with a numeric key pad.
In a further embodiment, a gateway acts as a two-way adapter between a “guest” device keyed with a “guest” cryptographic key and the trust web devices that are keyed with the group cryptographic key. The gateway converts communications in the peer networking connectivity protocol encrypted using the guest cryptographic key into communications encrypted using the group cryptographic key, and vice-versa. This enables the guest device to inter-operate in the trust web without having to provide the group cryptographic key to the guest device, which could potentially compromise the security of the trust web.
Additional features and advantages will be made apparent from the following detailed description of the illustrated embodiment which proceeds with reference to the accompanying drawings.